wo 2005/064892 1 PCT/SE2003/002100 



Method and system for handting context of data packet flows 

5 

FIELD OF INVENTION 

The present invention relates to a method for handling context of data packet flows, 
a network system, a Midcom Agent and a computer program product for performing 
the steps of said method. 

10 

BACKGROUND OF THE INVENTION 

The technical field relates to transfer of data packet flow related state and context 
information in access networks. 

1 5 Following documentation is regarded as state of the art: 

[1] J. Kempf (ed), "Problem Description: Reasons for Performing Context Transfers 
Between Nodes in an IP Access Network" (RFC 3374); http: / / wwwietf.org/ rfc/ 
rfc3374.txt 

20 [2] J. Loughney (ed) , ''Context transfer protocor,IETF, Internet draft, October 2003; 
http: / /www.ietf.org/html. charters /seamobv-charter.html . 

[3] G. Kenward (ed), "General Requirements for context transfer" ,IETF Internet 
draft, October 2002; http: / /www.ietf.org/html.charters/ seamobv-charter.html . 
[4]R.P. Swale et al. ,"Middlebox Communications (MIDCOM) Protocol Requirements", 
25 IETF RFC 3304; httn: / / www.ietf.org /rfc/ rfc3304.txt 

[5] B. Carpenter et al, "Middleboxes: Taxonomy and Issues", IETF RFC 3234, 2002; 
http://www.ietF.org/rfc/ rfc3234.txt 

[6]P. Srisuresh, "Middlebox Communications (MIDCOM) Architecture and 
framework", IETF RFC3303; http://www.ietf.org/rfc/ rfc3303.txt 
30 [7] R. Hancock (ed): Next Steps in Signalling: Framework", IETF Internet draft, 
October 2003; http: / / www.ietf.org/html.charters/nsis-charter.html 

For context transfer purposes, the organization IETF has developed the Context 
Transfer protocol (see references [1], [2], [3]). In these documents, the context is 
35 defined as the information on the current state of a service required to re-establish 
the service on a new subnet without having to perform the entire protocol exchange 
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with the mobile host from scratch and Context transfer is defined as the movement 
of context from router or other network entity to another as a means of re- 
establishing specific services on a new subnet or collection of subnets. 

5 In IP (Internet Protocol) access networks that support host mobility, the routing 
paths between the host and the network may change frequently and rapidly. For 
example, Mobile IP networks allow a mobile node or an entire moving network to 
change access router that provides the first IP layer hop seen from the mobile node 
or from a moving network's edge. When the mobile node changes access router (due 
10 to, for instance, mobility), there is a need to establish a new path, whose nodes 

should ideally provide similar treatment to the IP packets as was provided along the 
old routing path. 

In some cases, the host may establish certain context transfer candidate services 
15 on subnets that are left behind when the host moves. Examples of such services are 
Authentication, Authorization and Acounting (AAA), header compression and 
Quality of Service (QoS). In order for the host to obtain those services on the new 
subnet, the host must explicitly re-establish the service by performing the 
necessary signalling flows from scratch. This process may in some cases 
20 considerably slow the process of establishing the mobile host on the new subnet. 

During the fast handoff, state information has to be transferred between access 
routers. Examples of state information that could be useful to transfer are 

* 

Authentication, Authorization and Accounting (AAA) information, security .context, 
25 QoS properties assigned to the IP flow, header compression information, etc. 

A possibility is to simply move all the context from one access router AR to the 
other access router of a selected access point after handover. Said mechanism 
works properly when handling single IP flows. However, drawbacks have been 

30 recognized concerning services and sessions wherein more than one flow is 

involved. For example, Multimedia sessions may involve of several parallel IP flows, 
one for voice, one for video, and one for whiteboard. After a hand-over between two 
access points, it is not unusual that IP flows belonging to the same session are 
distributed on different radio interfaces of a terminal. In such a situation, the flows 

35 of a session are distributed on two access routers after the hand-over and- 
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associated context transfer. The context transfer must then be performed in both 
access routers, since there is no master access router that can assume 
responsibility for the session context. This would lead to a context sjmchronization 
problem since the session context may have to be renegotiated during a session. 
5 For example, the bandwidth of the session may be renegotiated. 

The transfer of IP flow related state and context information is facilitated by the 
IETF Context Transfer protocol (see reference [2]) . 

10 The IETF MIDCOM working group (WG) has examined scenarios and defined 

protocols for IP networks that contain entities that perform functions apart from 
traditional layer 3 (L3) routing, so called middleboxes (MB) (see references [4] , [5] , 
[6]) . A middlebox is defined as any intermediary device performing functions other 
than the normal, standard functions of an IP router on the datagram path between 

15 a source host and a destination host. Such middleboxes may require a context that 
is specific to the functions and services they perform. For instance, a Quality of 
Service scheduler may need to maintain some token bucket state associated with 
an IP flow (QoS context), a firewall may need to know about a security association of 
an IP flow (security context), etc. For the moment, it is possible to Ust 22 different 

20 kind of middleboxes that could be provided along an end-to-end path. 

Middleboxes embed application intelligence within the device to support specific 
application traversal. Middleboxes supporting the Middlebox Communication 
(MIDCOM) protocol will be able to externalize application intelligence into Midcom 

25 agents. Therefore, Midcom agents are logical entities which may reside physically 
on nodes external to a middlebox, possessing a combination of application 
awareness and knowledge of middlebox function. A Midcom agent may 
communicate and interact with one or more middleboxes. Said Midcom protocol 
between a Midcom agent and a middlebox allows the Midcom agent to invoke 

30 services of the middlebox and allow the middlebox to delegate application specific 
processing to the Midcom agent. Further, the Midcom protocol enables the , 
middlebox to perform its operation with the aid of Midcom agents, without resorting 
to embedding application intelligence. 
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The particular end-to-end path, along which some middleboxes may need context 
can traverse multiple operator domains. Herein, a domain or administrative 
(operator) domain is the collection of hosts, routers, middleboxes and the 
interconnecting networks managed by a single administrative authority or owner. 
5 The devices that operate in the same administrative domain share common security 

It 

features that are administered across the domain. It is an issue how to distribute 
the context to the middleboxes that need the context, since the operator domain 
where the hand-over occurred may be unaware of the particular middleboxes that 
are located in another provider's or operator's domain. 

10 

As mentioned, there is a need of a coordination mechanism for the transfer of 
context for flows that belong to the same session. 

One object with the invention is to offer a coordination mechanism for the handling 
15 of context associated to flows that belong to the same session. 

In simple terms, the problem that the current invention addresses is to define a 
context transfer procedure that meets the above requirements and the object of the 
present invention is to provide a solution to the stated problem. 

20 

SUMMARY 

The problem is solved according to the present invention by a procedure 
coordinating the transfer of context that is specific for each flow with the transfer of 
context that is common for aU flows. 

25 

The above-mentioned object is achieved by a method for handling context of data 
packet flows, a network system, a Midcom Agent and a computer program product 
for performing the steps of said method, in which the total context for a session is 
divided into one common context and one dynamic context per IP flow. The common 
30 context is handled by a centralized control node, such as a Midcom Agent, and the 
dynamic context is handled by a middlebox associated to an access router. The 
context transfer procedures for the two types of contexts are coordinated so that an 
unambiguous session control is maintained. 

35 Preferred embodiments are set forth in the depending claims. 
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An advantage with the present invention is that it enables session-oriented IP-flow 
control in multi-access networks. 

5 A further advantage is that the flows of a session may be distributed on different 
radio access points utilizing the knowledge that they belong to the same session, 
and origkiate from the same terminal. For example, the flows of a specific session 
may be distributed on different radio access points with the boundary condition 
that the access points belong to the same operator. The fulfilment of this boundary 
10 condition facilitates session management and charging. 

Yet another advantage is that the transfer of context is better organized and 
controlled with the Midcom Agent and middlebox architecture than in known 
architectures . 

15 

Further one advantage is that the division of the total context into common context 
and dynamic context results ia faster context transfer between access routers. The 
common context is stored in the central entities, i.e. the Midcom Agents, and the 
dynamic context is stored in the middleboxes and transferred between the access 
20 router nodes. Only the dynamic context will be moved, when a data packet flow 
changes to another access router within a domain. Less amount of transferred 
context results in faster networks. 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 

Figure 1 is a schematic block diagram illustrating a network system 

according to a preferred embodiment of the invention. 

Figure 2a is a flow chart showing a first part of the method according to 

the invention. The flow chart continues in figure 2b. 
30 Figure 2b is a flow chart showing a second part of the method according to 

the invention. The flow chart starts in figure 2a. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
35 Figure 1 is a schematic block diagram illustrating a network system according to a 
preferred embodiment of the invention. In the figure is illustrated Internet protocol 
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(IP) flow paths over a number of domains Dl-Dn between two end user terminals 
UTA, UTB. Said IP information flow is passing a number of middleboxes MB- Each 
domain comprises one Midcom Agent MA controlling at least one associated 
middlebox MB. The middleboxes are associated to router nodes that is routing the 
5 flow of data packets in accordance with their IP address. The IP flow is generated by 
one of the user terminals during an end~to-end session. The middleboxes MB store 
context data for each IP session flow. Once the middleboxes MB within a domain D 
receive context data, they establish and store the associated context. As user data 
packets arrive at the middleboxes MB of a domain D, the respective middlebox MB 

1 0 associate these packets with their proper context and provide them with 

appropriate context dependent service. Such context dependent service is specific to 
the respective middlebox MB. A middlebox MB has means for controlling its 
operation and function. It also comprises means for handling context, e.g. reading, 
sorting, selecting, deleting, writing, storing, etc. A middlebox has also means for 

1 5 communicating with its associated Midcom Agent by means of one or more suitable 
protocols. Further, a middlebox comprises means for conmiunicating with other 
middleboxes by means of one or more suitable protocol. According to this invention, 
the Middleboxes are provided with means for storing 22, i.e. a data storage, 
dynamic context. The middleboxes can be implemented by means of computer 

20 software program comprising coded instructions, when said computer program 
software is stored in a computer usable medium and run in a computer or 
processing means, such as e.g. a server unit, a microprocessor, PC, data 
processing unit, CPU, etc. 

As mentioned above, the network comprises a IP layer state-full protocol, for 
25 example NSIS, that is implemented by the user terminal as weU as aU involved 
middleboxes MB. (Said protocol is described further down in this description.) A 
vertical protocol, for example the Midcom protocol, allows Midcom Agents to 
distribute and/ or redistribute context information among middleboxes that are 
under control of said Midcom Agent. Said protocols contains information elements 
30 that allows the description of contexts. 

When a user terminal UT starts a session, it starts signalling along the end-to-end 
path UTA-UTB in order for the context, e.g. session related context, to get 
established in the middleboxes MB along the path UTA-UTB. That is, in all 
35 middleboxes MB, that the user session data is going to traverse, the proper QoS, 
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security or other context needs to be established and configured. The user 
terminals UT use a session layer, e.g. SIP/SDP (Session Initiation Protocol/ Session 
Description Protocol), and/ or an IP level signalling protocol, that supports the 
establishment and manipulation of arbitrary state information along the path of the 
IP flow. Such IP level stateful multi-domain protocol that is being standardized by 
the IETF is the group of protocols termed Next Steps in Signalling (NSIS) (see 
reference [7]). The NSIS protocol family is therefore the preferred IP level signalling 
protocol of the present invention. 

NSIS carries all information elements that are necessary to establish proper context 
in each domain D. The respective Midcom Agents MA that receive this signalling, 
examine the information elements and use the Midcom protocol to distribute, 
context information to the middleboxes MB that are under their control. Hence, the 
interface between separate Midcom Agents MA is a state-full, horizontal, and 
domain independent protocol. The NSIS protocol fulfil these requirements. The 
Interface between the Midcom Agent MA and its associated middleboxes MB is the 
Midcom protocol. 

A Midcom Agent MA has means for controlling its operation and function. It also 
comprises means for handling context, e.g. reading, sorting, selecting, deleting, 
writing, storing, etc. Midcom Agent MA has also means for communicatiag with its 
associated middleboxes MBs by means of one or more suitable protocols. Further, a 
Midcom Agent MA comprises means for communicating with other Midcom Agents 
MAs by means of one or more suitable protocol over a control plane. According to 
this invention, the Midcom Agents are provided with Context Dividers CD for 
dividing the total context for a session consisting of multiple IP flows and means for 
storing 20, i.e. a data storage, common context. The Midcom Agent MA can be 
implemented by means of computer software program comprisiag coded 
instructions, when said computer program software is stored in a computer usable 
medium and run in a computer or processing means, such as e.g. a server unit, a 
microprocessor, PC, data processing unit, CPU, etc. 

Domain Dl comprises two access points AP 1, AP 2 for mobile communication with 
mobile user terminals. Each access point API, AP2 comprises an access router AR 
(not shown), which is connected over an interface to a base station BS in a mobile 
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radio access network. User movement may cause a handover to a new base station 

« 

and a new access router. 

The change of access router AR results in a new IP flow path, and middleboxes MB 
5 along the new path have to be up-graded regarding the proper, i.e. the valid, context 
data. In figure 1 , user terminal UTA is communicating with user terminal UTB via a 
flow path starting in UTA that is communicating via a radio interface with the base 
station BS in access point API comprisitig an access router AR (not shown) and 
middlebox MB 1 1 . The flow of data packets will flow through the network, starting 

10 in middlebox MBl 1, passing a number of domains and middleboxes, which have 
the proper context for controlling and supporting the IP flow of data packets, and 
finally arrive at middlebox MBm, which is associated to an access router AR in the 
access point APm. Access point APm is capable of communicating with the user 
terminal UTB. The flow path in the network can be described as starting in 

1 5 middlebox MB 1 1 , passing through MB 13 to MBm. 

A situation is iUustrated in figure 1, wherein the User Terminal UTA is moving 
towards the access point AP2. If the terminal UPA is measuring the received signal 
strength from the surrounding base stations BS, the User Terminal UTA may find it 

20 necessary to perform a handover to the base station BS2 in AP2, as the signal 
strength from BSl (associated with API) becomes weaker than from BS2. The 
movement is therefore causing a layer 2 (L2) trigger in the terminal resulting in a 
handover to BS2 and AP2. Three positions 1, 2 and 3 for the moving user terminal 
UTA is given in figure 1 . The terminals UTA and UTB are involved in a multimedia 

25 session wherein three separate IP flows F1,F2,F3 (for example one for voice, one for 
video, and one for whiteboard ) are progressing simultaneously. Of different 
reasons, said separate IP flows may be connected to different access points of the 
network structure. In the first position, all these IP flows F1,F2,F3 may be 
connected to access point API. When the terminal has moved to the second 

30 position, only one of the separate IP flows, Fl, is connected to API, and the other 
two IP flows F2,F3 are connected to access point AP2. In position 3, ^when the 
terminal is somewhere between AP2 and access point AP, the two IP flows F2,F3 
that where connected to AP2 in position 2 are stiU connected to AP2, but the IP flow 
Fl is transferred to access point APS, which belongs to another domain, D2. 

35 
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The change of access router results in a new IP flow path, and middleboxes along 
the new path has to be up-graded regarding the proper, i.e. the valid, context data. 

According to the invention, the Midcom Agents comprise a context divider function. 
5 At session initiation, one of the User terminals starts signalling along the end-to- 
end path in order for the context to get established. The context divider divides the 
total context according to a predetermined schedule into one common context and 
one d3mamic context per IP flow. The common context is stored within the Midcom 
Agent, but the specific dynamic context data is distributed to that middlebox to 

10 which the special IP flow, to which the specific dynamic flow belongs, passes. The 
means for dividing the total context, context divider CD, for a session consisting of 
multiple IP flows in the Midcom Agents MA divides the context into two types of 
contexts. The first type is called the common context and includes information 
elements that are common for all flows in the session. Moreover, the common 

1 5 context includes such information about each flow in the session that is permanent 
over the lifetime of the session, or cam be renegotiated using e.g. session layer 
signalling. Examples of common context are session identity, flow identity and 
allocated bandwidth for each flow in the session. The second type of context is 
called dynamic contcKt. This context is defined for each flow and is updated 

20 frequently during a session. Examples of dynamic contexts are state information for 
IP header compression and packet schedulers. Further, dynamic context is related 
to event in the data path, such as the transmission or reception of a packet, and 
should therefore be processed in nodes along the data path, such as routers or 
middleboxes. On the other hand, common contexts are related to signalling events 

25 and should therefore be located in nodes that process session or IP layer signalling, 
such as a Midcom Agent. 

The requirements on the context transfer mechanism at hand-over are different for 
the two types of context, which will now be illustrated by means of figure 2, which 
30 is a flow chart of a preferred embodiment of the invention. The first step, step 100, 
is performed when a session between user terminals is initiated and the data 
packet flows arrives to the access routers of the access points: 

- dividing the total context associated to a session into common 
context, which is common to all flows of the session,^ and one 
35 dynamic context per data packet flow of the session (step 100). 
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The Midcom Agent will execute steps 102 and 104: 

storing said common context in a Midcom Agent of a first domain of 
the network structure(step 102); 

storing each dynamic context in a middlebox through which the 
5 associated flow passes(step 104). 

The common context is processed in a Midcom Agent MAI, called the first Midcom 
Agent, in a first domain D 1 that is able to control several access routers (within its 
domain), and therefore the common context only has to be transferred when the 
10 session is handed over to a middlebox associated to an access router in a second 
domain D2 controlled by a different Midcom Agent MA2, the second Midcom Agent. 

The d3mamic context transfer is performed every time a flow is handed over between 

access routers, step 106: 
15 - transferring dynamic context associated to a data packet flow, when 

a data packet flow is moved from a middlebox in an access point in 
the first domain to another middlebox in an access point in said first 
domsdn or to a middlebox of an access point in a second domain. 

20 When a dynamic context transfer is done to a middlebox MB of an access router 
that is controlled by another Midcom Agent MA there are two alternatives for the 
handling of the common context: 

1, If there are flows belonging to the session in a first domain Dl, even called the 
25 previous domain, the common context and the control of a session remain with the 
first Midcom Agent MAI, even called previous Midcom Agent MAI. The second 
Midcom Agent MA2, called the next Midcom Agent, will then be able to relay 
signalling messages between the first Midcom Agent MAI and a middlebox in the 
second domain D2 associated to the next Midcom Agent MA2. 
30 - keeping in said Midcom Agent MAI of the first domain D 1 the 

common context of data packet flows of a session and the control of 
the dynamic context of each flow in middleboxes MB through which 
the data packets of the session flows as long as there is one flow 
belonging to said session in said first domain Dl (step 1 10). 
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2. If all flows belonging to the session are in the second domain D2, called the next 
domain, the common context is transferred to the next Midcom Agent MA2, which 
then assumes control of the session. 

5 - determining whether all flows belonging to the session are moved 

from the previous domain Dl, or not (step 108); 

Transferring the common context of a session flow from the Midcom 
Agent MAI of the previous domain Dl to a Midcom Agent MA2 of a 
next domain D2 (having at least one of said flows) and also the 
1 0 control of the associated dynamic context stored in the middleboxes 

through which the data packets of the session flows, if all said flows 
have been transferred from the previous domain Dl (step 112), 

In both cases 1 and 2, the previous Midcom Agent MAI and the next Midcom Agent 
15 MA2 must establish communication with each other. This is handled by a 
middlebox (associated to the next Midcom Agent MA2 in the next domain D2), 
which knows the address of the next Midcom Agent MA2 via a standard domain 
intemal agent discovery procedure. There are two alternatives in step 114 for 
establishing communication between the two Midcom Agents MAI and MA2: 

20 

1. The middlebox (MB 15 in figure 1) associated with an access router in the next 
domain D2 learns the previous Midcom Agent's (MAI) address via the dynamic 
context transfer, and sends it to the next Midcom Agent MA2, which then registers 
with the previous Midcom Agent MAI. 

25 - obtaining by means in the middleboxes in the previous domain D 1 

the address of the Midcom Agent MAI in the first domain Dl from 
the dynamic context transfer between middleboxes in the previous 
domain Dl and next domain D2; 

using by means of the Midcom Agent MAI in the previous domain 
30 Dl said address for registering with and establishing communication 

with said Midcom Agent MA2 of said next domain D2. 

2. The middlebox associated with an access router in the next domain D2 learns the 
previous Midcom Agent's (MAI) address via the d3m.amic context transfer, and 

35 sends a request to the previous Midcom Agent MAI for registering with the next 
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Midcom Agent MA2. The request includes the address of the next Midcom Agent 
MA2. 

obtaining by means in the raiddleboxes in the next domain D2 the 
address of the Midcom Agent in the previous domain D 1 from the 
5 dynamic context transfer between middleboxes in the previous 

domain Dl and next domain D2; 

sending a request to the Midcom Agent MAI of the previous domain 
Dl, said request containing said address, for registering and 
establishing communication with the Midcom Agent MA2 of said 
10 second domain D2. 

Alternatively, said addresses is possible to get by using a database storing the 
domain addresses of all the Midcom Agents in the network structure. Then the first 
method for establishing communication between the two Midcom Agents MAI and 
15 MA2 will comprise following steps: 

obtaining by means in the middleboxes in the previous domain D 1 
the domain address of the Midcom Agent MAI of the previous 
domain D 1 from a database storing the domain addresses of all the 
Midcom Agents in the network structure; 
20 - using said address for registering with and establishing 

communication with said Midcom Agent MA2 of said next domain 
D2. 

The second method for establishing communication between the two Midcom 
25 Agents MAI and MA2 will comprise following steps: 

obtaining by means in the middleboxes in the next domain D2 the 
domain address of the Midcom Agent of the previuos domain from a 
database storing the domain addresses of all the Midcom Agents in 
30 the network structure; 

- sending a request to the Midcom Agent MAI of the previous domain 
Dl, said request containing said address, for registering and 
establishing communication with the Midcom Agent of said second 
domain. 



35 
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Alternatively, the first (previous) and second (next) Midcom Agent may have a 
Master-Slave relation. The first Midcom agent then instructs the second Midcom 
Agent to send signaling messages to the middleboxes in the domain of the second 
Midcom Agent. 

5 

The invention also relates to a Midcom Agent for handling context of data packet 
flows in a network system according to claims 9-16. 

The method may be implemented by means of a computer program product 
10 comprising the software code means for performing the steps of the method. The 

computer program product is run on processing means , such as e.g. a server unit, 
a microprocessor, PC, data processing unit, CPU, etc., within a network, or in a 
separate processing means connected to a network. The computer program is 
loaded from a computer usable medium. 

15 

The present invention is not Umited to the above-described preferred embodiments. 
Various alternatives, modifications and equivalents may be used. For example, the 
embodiments of the invention have been implemented by means of Internet Protocol 
technology (IP) . However, the invention are also applicable with ATM (Asynchronous 
20 Transfer Mode) technology and MPLS (Multi Protocol Label Switching) . 

Therefore, the above embodiments should not be taken as limiting the scope of the 
invention, which is defined by the appending claims. 



